原文：Psychological Ownership: Own the Right Things
工作上我們很常聽到一句話：「要有 Ownership。」尤其是 PM、UX、設計這類角色，好像越願意扛責任、越把事情當成自己的，就代表越成熟、越有責任感。
本篇文章說明 Ownership 其實也有另一面：不是擁有感越強越好，而是你把這份 Ownership 放在哪裡。 如果你把它放在自己真的能控制的事情上，它會讓你更主動、更投入；但如果你把它放在其實屬於整個團隊、甚至根本不在你控制範圍內的事情上，最後很容易變成防衛、挫折，甚至 Burnout。
Psychological Ownership 可以簡單理解成：某個東西其實不是真的「屬於你」，但你心理上已經把它當成自己的。可能是一個 Prototype、一個專案、一個研究洞察，甚至是一整個產品。這種感覺很常見，像是你會因為「這是我做的設計」而感到驕傲；Stakeholder 一質疑，就下意識想防衛；工程實作和原本設計差很多時，也可能會特別生氣。
這種 Ownership 主要會從三個地方長出來：你能控制它、你非常了解它，以及你投入了很多時間和心力。 這也很好理解，因為不管是 PM、UX 還是 Designer，只要一個專案跟了幾個月，需求是你梳理的、Flow 是你想的、細節你最熟，真的很難完全沒有「這是我的東西」的感覺。
問題是，Psychological Ownership 本身不是壞事。它確實可能讓人更有動機、更願意主動處理問題，也更有工作成就感。但當 Ownership 放錯地方，就很容易變成「這是我的設計，所以不要動」、「這是我的想法，所以你不同意就是你沒理解」，甚至開始不想分享資訊、不想接受別人的意見。
文章第一個很有感的情境，是當你很喜歡自己一個人做。需求丟過來，沒有人干涉，你可以自己決定全部，看起來很舒服，但這時候其實很容易開始高估自己的想法、低估其他人的 input。
尤其專案一開始的 Concept 通常假設最多，如果這時候又因為「終於沒人來干涉我」而感到特別輕鬆，就要小心了。因為你可能不是在保護思考時間，而是在保護自己的想法不被挑戰。
這裡我覺得很適合 UX 和 PM。很多時候一個人先想方案確實比較快，但如果一開始就把「這是我的 Solution」抓得太緊，後面工程、商務或使用者提出不同角度時，就很容易開始變成 defend，而不是一起解問題。
所以這裡比較好的 Ownership，不是「我要擁有這個 Idea」，而是 「我要對協作過程負責。」 也就是更早讓不同角色一起進來，讓 Idea 還沒完全定型之前就被挑戰，而不是等全部做完才拿出去 Review。
我覺得這篇另一個很值得記住的地方，是它提醒我們：「我做的 Prototype」和「產品最後會怎麼被做出來」其實是兩件事。
Prototype 做得再漂亮，如果技術上做不到、時程趕不上、商業上沒有價值，那它也不會變成一個成功的產品。真正能上線的東西，一定是 UX、Engineering、Business、Timeline 一起妥協和決策的結果。
所以文章很建議把語言也一起改掉。與其一直說「我的設計」、「我的 Prototype」，可以開始多用「我們的設計」、「我們要怎麼處理這個問題」。這個看起來只是 wording，但其實是在提醒自己：這個成果不是我要別人照著執行的作品，而是團隊共同完成的東西。
我覺得這對 PM 也很適用。有時候需求規格寫久了，也會很容易變成「這是我定義好的需求，你們照著做就好」，但實際上需求到了工程端、QA、設計端，大家都可能看到你原本沒看到的問題。如果 Ownership 是放在「讓這個東西成功」，就比較能接受原本方案被改；但如果 Ownership 是放在「這是我的規格」，就很容易覺得被挑戰。
另一個很真實的情境，是收到 Feedback 的時候。
有人在會議上說「這個設計不太行」，你開始解釋。對方還是不認同，你就講得更細、找更多理由，心裡開始覺得：「他只是沒理解，只要我再講清楚一點，他一定會同意。」
這其實就是 Psychological Ownership 在作怪。當設計被當成自我延伸時，別人在反對那個設計，就很容易被感覺成「在反對我」。
但文章也不是叫我們什麼 Feedback 都接受。如果對方的建議會真的傷害使用者、犧牲 Accessibility，或明明有 User Evidence 卻被忽略，那當然還是需要堅持。重點是先問自己：我現在是在 defend 使用者證據，還是在 defend 我自己的偏好？
我覺得這個問題超有用。因為很多爭論最後不是誰比較專業，而是雙方都在保護自己的版本。如果真的沒有足夠 Evidence，那比起比誰講得比較大聲，可能更好的方式就是拿去測，讓使用者幫忙回答。
這一段我也覺得很貼近真實工作。
Sprint Demo 一打開，發現最後 Build 出來的東西跟設計稿差很多，有些細節被拿掉、流程被簡化，第一個念頭可能就是：「工程怎麼又亂改」、「是不是根本不在意 UX？」
文章在這裡帶到一個心理學理論：Fundamental Attribution Error（基本歸因謬誤）。也就是我們很容易把別人的行為歸因成他的個性或態度，卻忽略他當下的情境。
例如看到工程沒照稿做，很容易想成「他不重視品質」，但背後也可能是 Deadline、技術限制、臨時 Incident，或某個你根本不知道的優先事項。
這不代表差異就不用處理，而是不要太快下結論。比較有用的做法是去理解發生什麼事，把還沒修掉的問題記成 UX Debt，再反過來看自己在 Sprint 中有沒有本來可以做、但沒有做的事，例如中途 Check-in 或 Design QA。
這裡我覺得文章講得很好：與其一直擁有自己的失望，不如去擁有自己還能改善的流程。
講到這裡可能會覺得，那什麼都不能 Own 嗎？其實不是。
這篇最後反而列出了一些很值得真正擁有的東西：你的 Judgment、Actions、Growth、Values、Boundaries、Relationships。
這些事情最大的共通點是：別人拿不走，而且真的在你的控制範圍內。
你可以決定怎麼判斷資訊、怎麼回應 Feedback、要不要持續學習、要不要堅持自己的價值、怎麼設定工作界線、要建立什麼樣的職場關係。這些才比較適合把 Ownership 放得重一點。
反過來，產品最後長什麼樣子、別人會不會採納你的建議、公司最後怎麼排優先順序，這些本來就不是一個人能控制的，所以可以 Own，但要輕一點。
我覺得這篇很適合 PM 看，因為 PM 可能是最容易被「Ownership」這個字綁住的角色之一。專案 Delay、需求沒講清楚、Stakeholder 不滿、工程卡住，好像最後都會變成「PM 要負責」。
但我看完之後反而覺得，PM 的 Ownership 不應該是「所有結果都要控制」，而是 對自己能影響的那一段負責。 例如需求有沒有定義清楚、風險有沒有提早說、不同角色有沒有被拉進來、決策依據有沒有被記錄、出了問題後有沒有把流程改善。
至於工程最後一定要用哪個實作、主管最後一定要選哪個方案，這些本來就不是 PM 可以完全控制的。如果把這些也全部當成「我的責任」，很容易最後只剩下挫折。
我覺得可以直接借用文章裡的思路問自己兩件事：「我現在有沒有 User Evidence？」以及「如果今天這個方案不是我提出的，我還會 defend 得這麼用力嗎？」
如果今天真的有 Evidence 支持，那就應該說清楚；但如果其實只是「我覺得這樣比較好」，那可能就值得再聽一下別人的考量。
我覺得這對 UX 很重要，因為專業不是「我的設計不能被改」，而是能不能清楚說明 Trade-off，甚至知道什麼時候該讓 Data 或 User Test 幫忙決定。
我覺得是，而且這篇最有感的地方就在這裡。
如果一直把那些不在自己控制範圍內的東西當成「我必須負責」，每天都會有很多挫折。設計被改會氣、需求沒被採用會氣、優先順序改了也會覺得自己的心血被浪費。
但很多事情本來就是 Shared Ownership。
所以真正需要練的可能不是「更有 Ownership」，而是 分清楚什麼要抓緊、什麼要放鬆。
這並不是擺爛，也不是「反正不是我的事」，而是把力氣放到真正能改善的地方。像自己的判斷、溝通、協作方式、成長和價值，這些才是投入越多越有累積的東西。
看完這篇之後，我最大的感覺是，以前聽到「Ownership」時，很容易直接理解成「這件事就是你的，你要想辦法負責到底」。但這篇讓我覺得，成熟的 Ownership 可能反而不是什麼都抓住，而是知道 什麼真的屬於自己，什麼本來就屬於團隊。
設計稿不是你的作品集作品而已，它最後要和技術、商業、時程一起活下來；Feedback 也不一定是在否定你，而是在共同決定產品；Build 出來和原本不一樣，也不一定代表別人不在乎品質。
所以比起一直想「我要 Own 這個專案」，我現在會更想問：這件事情裡，到底哪一部分真的在我的控制範圍內？
我覺得這才是這篇最值得帶走的一點：Own the right things。 把重的 Ownership 放在自己的 Judgment、Actions、Growth、Values、Boundaries 和 Relationships 上；對那些本來就要和別人一起完成、一起決定的事情，則學著 Own 得輕一點。
iThome鐵人賽
看影片追技術